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ABSTRACT 


Concurrent Euclid (CE) is a programming language designed for 
implementing software that is efficient, reliable and portable. 
It is particularly suited for implementing operating systems, 
compilers and specialized microprocessor applications. It can 
serve as the basis for producing verifiable system software. 


CE has been designed to allow its compiler to be small, fast 
and portable. Such a compiler exists, with replaceable high- 
quality code generators for various target machine architectures 
including the PDP-1l1, MC68000 and MC6809. 
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INTRODUCTION 


This report defines the programmming language Concurrent Eu- 
clid, or CE. CE is designed for implementing software, and is 
particularly suited to implementing operating systems, compilers 
and specialized microprocessor applications. Because it is based 
on Euclid [1], it can also serve as the basis for implementing 
software which is to be formally verified. 


CE consists of a subset of the Euclid programming language 
called -Sequential Euclid or SE and a set of concurrency exten- 
Sions to Euclid based on monitors [2]. The first section of this 
document defines the SE language independently of Euclid. The 
second section describes the concurrency features added to form 
CE. The last section describes CE features that Support separate 
compilation of procedures, functions, modules and monitors. A 
thorough understanding of the basic concepts of the Pascal family 
of programming languages is assumed throughout. 


I. THE SE LANGUAGE 


This section describes the SE subset of Euclid. SE is defined 
independently of Euclid and no previous knowledge of the Euclid 
programming language is required. An understanding of the basic 
concepts of the Pascal family of programming languages is as- 
sumed .- 


IDENTIFIERS AND LITERALS 


An identifier consists of any string of at most 50 letters, 
digits and underscores (_) beginning with a letter. Upper and 
lower case letters are considered identical in identifiers and 
keywords, hence aa, aA, Aa and AA all represent the same identi- 
fier. Keywords and predefined identifiers of Euclid, SE and CE 
must not be redeclared. A list of these is given in Appendix 2. 


A string literal is any sequence of one or more characters not 
including a quote (') surrounded by quotes. Within strings, the 
characters quote, dollar sign, new line and end of file are 
represented as $', $$, $N and SE respectively. As well, ST, $S 
and $F may be used for tab, space, and form feed respectively. 


A character literal is a dollar sign ($) followed by any 
single character. The character literals corresponding to quote, 
dollar sign, space, tab, form feed, new line and end of file are 
$$', $$$, $SS, S$$T, SSF, SSN and SSE respectively. 


In every implementation, the character set for string and 
character literals will contain at least the upper and lower case 
letters A-Z and a-z, the digits 0-9 and the special characters 
"2,338? () CL) £}4+-*/<=>'S#7 1&3", space, tab, form feed, new line and 
end of file. Character values are ordered such that A<B<C<...<Z, 
a<b<c<...<z and 0<1<2<...<9. Ordering of character values is 
implementation dependent otherwise. 


An integer literal is a decimal number, an octal number or a 
hexadecimal number. A decimal number is any sequence of decimal 
digits. An octal number is any sequence of octal digits followed 
by #8. A hexadecimal number is any sequence of hexadecimal di- 
gits (represented as the decimal digits plus the capital letters 
A through F) beginning with a decimal digit and followed by #16. 
Negative values are obtained using the unary - operator; see 
"Expressions". 


In every implementation, the range of integer literals will 
include at least 0 through 65535. . 


SOURCE PROGRAM FORMAT 


A comment is any sequence of characters not including comment 
brackets Surrounded by the comment brackets { and }. Comments 
may cross line boundaries. 


A separator is a comment, blank, tab, form feed or source line 
boundary. Programs are free-format; that is, the identifiers, 
keywords, literals, operators and special characters which make 
up a program may have any number of separators between them. 
Separators cannot be embedded in identifiers, keywords, literals 
or operators, except that blanks may appear as part of the value 
of a string literal. Identifiers, keywords and literals must not 
cross line boundaries. At least one separator must appear 
between adjacent identifiers, keywords and literals. 


SYNTACTIC NOTATION 
The following sections define the syntax of SE. 


The following notation is used: 


{item} means zero or more of the item 
[item] means the item is optional 


Keywords are given in lower case. Special symbols are enclosed 
in double quotes ("). 


The following abbreviations are used: 
id for identifier 
expn for expression 
typeDefn for typeDefinition 
Semicolons are not required, but they may optionally appear 
following statements, declarations and import, export and checked 
clauses. 


PROGRAMS 


A main program consists of a module declaration. 


A program is: 


 moduleDeclaration 


Execution of a program consists of initializing the main module, 
see "Modules". 


Modules, procedures and functions can be compiled separately; 
see “Separate Compilation". 


MODULES 
A moduleDeclaration is: 


var id ":" 

module 
[imports "(" [var] id {"," [var] id} ")"] 
(exports aoe da id se id} ye] 
{[not] checked] 
{declarationInModule} 
{initially 

procedureBody] 
end. module 


Execution of a module declaration consists of executing the 
declarations in the module and then the “initially” procedure of 
the module. Execution of a program consists of executing the 
main module declaration in this way. 


Module declarations may be nested inside other modules but 
must not be nested inside procedures and functions. 


A module defines a.package of variables, constants, types, 
procedures and functions. The interface of the module to the 
rest of the program is defined by its imports and exports 
clauses... 


The imports clause lists the global identifiers which are _ to 
be visible inside the module. Variable, collection and module 
identifiers nay be imported “var" (or not). Imported variables 
can be assigned to or passed aS var parameters within the module 
only if they are imported "var". Elements of an imported collec- 
tion can be allocated, freed, assigned to or passed as var 
parameters only if the collection is imported “var". Procedures 
of an imported module can be called only if the module is impor- 
ted "var". Imported identifiers must not be redeclared inside 
the module. 


The exports clause lists those identifiers defined inside the 
module which may be accessed outside the module using the "." 
operator. Exported variables cannot be assigned to or passed as 
var parameters outside the module. Elements of exported collec- 
tions cannot be allocated, freed, assigned to or passed as var 
parameters outside the module. Unexported identifiers cannot be 
referenced outside the module. 


Named types declared inside a module are opaque outside the 
module, that is, they are not considered equivalent to any other 
type. Variables and constants whose type is opaque cannot be 
subscripted, field selected or compared. 


Modules may be “checked"; this causes all assert statements, 
subscripts and case statements in the module to be checked _ for 
validity at run-time. [In addition, a particular implementation 
may check other conditions such as ranges in assignments) and 
overflow in expressions. Modules not already nested inside an 
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unchecked module are checked by default and must be explicitly 
declared “not checked" to turn off run-time checking. 


Even though declared like variables, modules are not variables 
and cannot be assigned, compared, passed as parameters or expor- 
ted. 


Modules can be separately compiled if desired; see “Separate 
Compilation". 


DECLARATIONS 
A declarationInModule is one of the following: 


- constantDeclaration 

- variableDeclaration 

. typeDeclaration 

- variableBinding 

- moduleDeclaration 

- collectionDeclaration 
» procedureDeclaration 
h. functionDeclaration 
i. converterDeclaration 
J. assert ["(" expn ") "J 


Forms (a) through (i) are declarations for new identifiers as 
explained in the following sections. Form (j) is an assert sta- 
tement; see “Statements". An identifier must be declared textu- 
ally preceding any references to it. 


CONSTANT DECLARATIONS 
A constantDeclaration is one of: 


a. [pervasive] const id ":=" manifestExpn 
b. [pervasive] const id ":" typeDefn ":=" expn 
Cc. [pervasive] const id “:" typeDefn ":=" 

"(" manifestExpn {"," manifestExpn} ")" 
d. [pervasive] const id ":=" stringLiteral 


A constantDeclaration gives a name to a value which is con- 
Stant throughout the scope of the declaration. The value of a 
scalar constant can be manifest or nonmanifest. A manifest ex- 
pression is one whose value is known at compile-time (see “Mani- 
fest Expressions"). A nonmanifest expression must be evaluated 


at run-time. Non-Scalar values are always considered nonmani- 
fest. 


Form (a) defines a.manifest named constant. The type of the 
constant is the type of the value expression, which must be mani- 
fest. Manifest named constants are not represented at run time 
since their values are always known at compile time. 


Form (b) declares a nonmanifest named constant of the 
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specified type. The value of the expression may be manifest or 
nonmanifest, and must be assignable to the constant's type. 
References to nonmanifest named constants are always considered 
nonmanifest even if their value is manifest. 


Form (c) declares an array constant. The typeDefn must be an 
array type or named array type whose component type is scalar. 
The list of expressions gives the values of the elements of the 
array constant. The element values must be manifest expressions 
asSignable to the element type of the array. The number of 
element values specified must be exactly the number of elements 
in the array. | 


Form (d) allows declaration of an array constant using a 
string literal value. The type of the constant is “packed array 
1l..n of Char" where n is the length of the string literal. 


Constants deciared using "pervasive" are automatically impor- 
ted into all subscopes of the scope in which they are declared. 
Such constants need not be explicitly imported. 


.VARIABLE DECLARATIONS 
A variableDeclaration is: 


{register] var id ["(" at manifestExpn ")"] ":" typeDefn 
[":=" expn] 


A variableDeclaration declares a variable of the specified 
type. The "at" clause declares a variable at an absolute machine 
location. Variables may optionally be declared with an initial 
value which is assigned to the variable when the declaration is 
executed. The initial value expression must be assignable to the 
variable's type. 


Local variables in procedures and functions may optionally be 
declared "register". This is a hint to the compiler that it 
should attempt to allocate the variable to a register. Register 


variables cannot be bound to nor passed to a reference parameter. 
A register variable declaration cannot have an “at" clause. 


TYPES AND TYPE DECLARATIONS 
A typeDeclaration is: 
[pervasive] type id "=" typeBody 


The typeBody is one of: 


a. typeDefn 
b. forward 


A typeDeclaration gives a name to a type. The type name can 
subsequently be used in place of the full type definition. A 
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named type is equivalent to the type that it names (except when 
exported, see "Type Equivalence and Assignability"). 


Named types may optionally be declared "“pervasive". Type 
names declared using “pervasive" are automatically imported into 
all subscopes of the scope in which they are declared. Such 
types need not be explicitly imported. 


Form (b) declares a forward type. A forward type declares a 
type name whose definition will be given in a later type declara- 
tion in.the scope. A forward type can be used only as_ the 
element type of a collection until its real type definition is 
given. This allows the declaration of collections whose elements 
contain pointers to other elements in the collection. 


A typeDefn is one of the following: 


standardtType 

manifestConstant ".." manifestExpn 
[packed] array indexType of typeDefn 
set of baseType 

[packed] recordType 


pointerType 
namedType 
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The standardTypes are: 


SignedInt - signed integer, implementation 

| | defined range (at least -32768..32767) 

UnsignedInt - unsigned integer, implementation 
defined range (at least 0..65535) 

LongInt - signed integer, implementation 
defined range (typically 32 bits) 

ShortInt - unsigned integer, implementation 
defined range (typically a byte) 

Boolean - values are "true" and "false" 

Char - single character 

StorageUnit - no operations or literals, smallest 
addressable memory unit (typically a 
byte) 

AddressType - implementation defined integer range 


The standard types and the constants true and false are impli- 
citly declared pervasive in the global scope and need not be 
imported. 


Form (b) is a subrange type. The leading constant must be a 
(possibly negated) literal or manifest named constant and gives 
the lower bound of the range of values of the type. The expres- 
sion, which must be manifest, gives the upper bound of the range. 
The bounds must be both. integer values or both character values. 
The lower bound must be less than or equal to the upper bound. 


A scalar type is a subrange, pointer or one of the standard 
types. 


Form (c) is an array type. The indexType must be a_ subrange 
type, Char or a named type which is an indexType. The indexType 
gives the range of subscripts. The typeDefn gives the type of 
the elements of the array. 


Elements of an array variable are referenced using subscripts 
(see “Variables and Constants") and themselves used as variables. 
Array variables and constants may be assigned (but not compared) 
as a whole. 


Arrays can be "packed", which allows the compiler to pack the 
elements more efficiently. The type of string literals is "pack- 
ed array 1l..n of Char" where n is the length of the string. 


Form (d) is a set type. The baseType of the set must be a 
subrange of integer with lower bound 0 or a namedType which is a 
baseType. An implementation may limit the upper bound of a set 
type to insure efficient code; this limit will be at least 15. 


A recordType is: 


record 


var id ":" typeDefn 
{var id ":" typeDefn} 
end record 


Variables declared using a.record type have the fields given 
by the variable declarations in the recordType. Fields of a 
record variable may be referenced using the "." operator (see 
"Variables and Constants") and themselves used as variables. 
Record variables may be assigned (but not compared) as a whole. 


The variable declarations in a record type must not have ini- 
tial values and cannot be declared using "register" or "“at" 
clauses, 


Records can be “packed", which allows the compiler to pack the 
elements more efficiently. 


A pointerType is: 
"*" collectionId 


Variables declared using a pointerType are pointers to dynami- 
cally allocated and freed elements of the specified collection; 
see "Collections". Pointer variables are used as subscripts of 
the specified collection to select the element to which they 
point. The selected element can be used as a variable. Pointer 
variables may be assigned, compared for equality and passed as 
parameters. 


A namedType is: 
{moduleId "."] typeld 
The typeId must be a previously declared type name. Type 
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names exported from a module are referenced outside the module 
using the "." operator. 


TYPE EQUIVALENCE AND ASSIGNABILITY 
Two types are defined to be equivalent if they are 
(a) subranges with equal first and last values 


(b) arrays (both packed or both unpacked) with 
equivalent index types and equivalent component 
types 


(c) sets with equivalent base types 
(d) pointers to the same collection 


A declared type identifier is equivalent to the type it names, 
with the following exception. When an exported type identifier 
is used outside its module, as "moduleld.typeId", it is a unique 
type, equivalent to no other type. 


Each type definition for a record type creates a new type that 
is not equivalent to any other record type definition. 


An array value can be assigned to an array variable, a_ record 
value assigned to a record variable, a set value assigned to a 
set variable and a pointer value assigned to a pointer variable 
only if the source and target of the assignment have equivalent 
types. 


An expression can be assigned to a scalar variable only if (i) 
the "root" type of the expression and the "root" type of the 
variable are equivalent, and (ii) the value of the expression is 
in the range of the variable's type. The "root" type of Char and 
character subrange types is Char. The root type of SignedInt, 
UnsignediInt, LongInt, ShortInt, AddressType and integer subranges 
is integer. The root type of any other type is the type itself. 


A variable can be passed to a reference parameter only if its 
type is equivalent to the parameter type. An expression can be 
passed to a value parameter only if it is assignable to the 
Parameter type; see “Procedures and Functions". 


VARIABLE BINDINGS 
A variableBinding is one of: 
a. bind [register] [var] id to variable 
b. bind "(" [register] [var] id to variable 
{"," [register] [var] id to variable} ")" 


A variableBinding declares a new identifier for an arbitrary 
variable reference which may contain subscripts and he 
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operators. The new identifier is subsequently used in place of 
the variable reference within the scope in which the binding 
appears. If the bound variable is to be assigned to or passed to 


a var parameter, the binding must be declared using "var". SE 
does not allow "aliasing" of variables (i.e., having two names 
for the same variable in a scope). Hence the "root" variable 


(the first identifier in the variable reference) becomes inacces- 
sible for the scope of the binding. 


Form (b) allows bindings to different elements or fields of 
the same variable or module. Since SE does not allow aliasing of 


variables, bindings to the same field, element or variable are 
not allowed. 


Local binds in procedures and functions may optionally be 
declared "register". This is a hint to the compiler to attempt 
to allocate the bind to a register. 


Elements of packed arrays and fields of packed records cannot 
be bound to. 


COLLECTIONS 
A collectionDeclaration is: 
var id “":" collection of typeDefn 


A collection is essentially an array whose elements are dynam- 
ically allocated and freed at run-time. Elements of a collection 
are referenced by subscripting the collection name with a varia- 
ble of the collection's pointer type. This subscripting selects 
the particular element of the collection located by the pointer 
variable. 


Elements of a collection are allocated and freed dynamically 
by calls to the built-in operations New and Free. "C.New(p) " 
allocates a new element in the collection C and sets p to point 
at it. I£ no more space is available then p is set to "C.nil". 
"C.Free(p)" frees the element of C pointed at by p and sets p to 
"C.nil". In each case p is passed as a var parameter and must be 
a variable of the pointer type of C. These operations are invok- 
ed as statements in procedures, see "Statements". They cannot be 
used in functions. 


The built-in constant "C.nil" is the null pointer value _ for 
the collection. 


Collections themselves cannot be assigned, compared or passed 
aS parameters. 
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PROCEDURES AND FUNCTIONS 
A procedureDeclaration is: 


procedure id ["(" [var] id ":" parameterType 
{"," [var] id ":" parameterType} ")"] "=" 
procedureBody 


A functionDeclaration is: 


function id ["(" id ":" parameterType 
Lge? id. ee parameterType} a ad 
returns id ":" resultType " 
procedureBody 


A procedure is invoked by a procedure call statement, with 
actual parameters if required. A function is invoked by using 
its name, with actual parameters if required, in an expression. 


A procedure may return explicitly by executing a return Ssta- 
tement or implicitly by reaching the end of the procedure body. 
A function must return via “return(expn) ". 


Procedures and functions may optionally take parameters, the 
types of which are defined in the header. The parameters can be 
referred to inside the procedure or function using the names 
declared in the header. Parameters to a procedure may be de- 
clared using "var", which means the parameter may be assigned to 
or further passed aS a var parameter inside the procedure. 
Parameters declared without using “var" are constants and cannot 
be assigned to or passed aS var parameters. Functions are not 
allowed to have any side-effects and cannot have var parameters. 
Only variable references can be passed to var parameters. 


A parameter is a reference parameter if it is declared using 
"var" or if its type is an array or record. Other parameters are 
value parameters. Hence, a value parameter is a non-var 
parameter whose type is a scalar or set. 


A parameterType is one of: 


a. typeDefn 

b. [packed] array manifestConstant ".." parameter of 
typeDe fn 

c. universal 


The type of a variable, record or array passed to a reference 
parameter must be equivalent to the parameter's type with the 
following exceptions. (1) The upper bound of the index type of 
an array parameter can be declared using the keyword "parameter" 
in which case any array whose element type and index type lower 
bound are equivalent to the parameter's can be passed to. the 
parameter. (2) The type of a parameter can be specified as 
"universal", in which case a variable or non-manifest named con- 
Stant of any type can be passed to the parameter. Inside the 
procedure, a universal parameter is equivalent to a parameter of 
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type “array 1..parameter of StorageUnit", where the upper bound 
is the size of the actual parameter in StorageUnits. Parameters 
declared using “parameter” or “universal" do not have the ".size" 
Standard component and cannot be assigned or compared as a whole. 
(Note: Full Euclid does not allow forms (b) and (c).) 


The type of an expression passed to a value parameter must be 
assignable to the parameter's type. 


SE does not allow "aliasing" of variables (i.e., having two 
names for a given variable or part of a given variable in the 
Same scope). Hence a variable or part of a variable which is 
imported directly or indirectly into a procedure cannot be passed 
to a reference parameter of the procedure. (A variable is 
directly imported if it appears in the procedure's import list. 
It is indirectly imported if an imported module or _ procedure 
directly or indirectly imports it.) 


Elements of packed arrays and fields of packed records cannot 
be passed to reference parameters. 


The returns clause defines the result type of a function. The 


return identifier is: required for compatibility with full Euclid 
but cannot be referenced. 


A resultType is one of: 


a. standardType 

b. manifestConstant ".." manifestExpn 
c. set of baseType 

dad. pointerType 

e. namedType 


The result type of a function must be a scalar type or set. 
The expression in a function's return statement must be assigna- 
ble to the result type. 


A procedureBody is: 


{imports "(" [var] id {"," [var] id} ")"] 
begin 

{{not] checked] 

{declarationInRoutine} 

{statement} 
end [id] 


The identifier following the "end" must be the procedure or 
function identifier. If the procedure is the initially procedure 
of a module then the end identifier must not be present. 


The imports clause of a procedure or function specifies those 
global identifiers which are to be visible inside the procedure 
or function. Only those variables imported into a procedure 
using "var" may be assigned to or passed to a var parameter in- 
side the procedure. Functions are not allowed to have side- 
effects and cannot import anything “var". This restriction is 
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transitive; hence a function cannot import a procedure which 
imports anything "var". A procedure or function which is recur- 
sive must explicitly import itself. 


Procedures and functions may be “checked"; this causes assert 
statements, subscripts and case statements to be checked for 
validity at run-time. In addition, a particular implementation 
may check other conditions, such as ranges in assignments’) and 
overflow in expressions. Procedures and functions not nested 
inside an unchecked module are checked by default and must be 
explicitly declared "not checked" to turn off run-time checking. 


A procedure returns when it executes a return statement or 
reaches the end of the procedure. A function is executed simi- 
larly but must return via “return(expn) ". 


Procedures and functions can be separately compiled; see 
"Separate Compilation". 


A declarationInRoutine is one of: 


a. constantDeclaration 
b. variableDeclaration 
Cc. typeDeclaration 

d. variableBinding 

e. collectionDeclaration 
f. converterDeclaration 
g. assert ["("expn") "] 


Modules, procedures and functions cannot be nested inside a 
procedure or function. Form (g) allows assert Statements’ to 


appear in declaration lists. 


TYPE CONVERTERS 
A converterDeclaration is: 
converter id "(" typeId ")" returns typeld 


A converterDeclaration declares a type converter. A type con- 
verter can be used to convert a variable or nonmanifest named 
constant to a type other than its declared type. Both the 
parameter and result type of a type converter must be named or 
standard types. An implementation is not expected to generate 
any code for a type conversion. 


The type of a converted variable or constant must be 
equivalent to the converter's parameter type. Expressions, 


literals, manifest values, elements of packed arrays and fields 
of packed records cannot be type converted. 


If the size of the target type is larger than the size of the 
source type, or the alignment of the target type iS more _ con- 
strained than the alignment of the source type, then the conver- 
sion may be meaningless. 
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STATEMENTS 
A statement is one of: 


a. variable “:=" expn 
b. [moduleId"."] procedureId ["(" expn {"," expn} ") "] 
“cc. assert ["("expn") "] 
qd. return ["("expn") "] 
e. if expn then 
{statement} 
{elseif expn then 
{statement} } 
{else 
{statement} ] 
end if 
fF. loop 
{statement} 
end loop 
g. exit [when expn] 
h. case expn of 
manifestExpn {"," manifestExpn} “=>" 
{statement} 
end manifestExpn 
{manifestExpn {"," manifestExpn} "=>" 
{statement} 
end manifestExpn} 
[otherwise "=>" 
{statement} ] 
end case 
i. begin 
{declarationInRoutine} 
{statement} 
end 
j- collectionId "." New "(" variable ")" 
k. collectionId "." Free "(" variable ")" 


Form (a) is an assignment statement. The expression is 
evaluated and the value assigned to the variable. The expression 
must be assignable to the variable type; see “Type Equivalence 
and Assignability". 


Form (b) is a procedure call. An exported procedure is called 
outside the module in which it was declared using the "." opera- 
tor. 


The type of an expression passed to a value parameter must be 
assignable to the parameter's type. The type of a variable or 
value passed to a reference parameter must be equivalent to the 
parameter's type. If the upper bound of the type of an array 
parameter is declared using "parameter", any array whose element 
type and index type lower bound are equivalent to the parameter's 
can be passed to the parameter. 


An actual parameter passed to a var parameter must be a varia- 
ble, a bound variable or avar formal parameter. If it is an 
imported variable, it must have been imported using "var". Since 
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SE does not allow aliasing of variables, a variable or part of a 
variable which is passed to a reference parameter cannot be 
passed to another reference parameter of the same call. 


Form (c) iS an assert statement. The parenthesized expression 
is optional; if it is omitted, it can be replaced by a comment. 
If present, it must be of type Boolean. The expression is 
evaluated and checked at run time if it appears in a checked 
scope. Assert statements may appear in both statement lists and 
declaration lists. They cannot appear inside records. 


Form (d) is a return statement. The return statement causes 
an immediate return from the procedure or function when executed. 
The optional parenthesized expression gives the value to be re- 
turned from a function. The return expression must be assignable 
to the function's result type. The return expression is required 
for function returns. It is forbidden for procedure returns. A 
function must return via a return statement and not implicitly by 
reaching the end of the function body. A procedure may return 
either via a return statement or implicitly by reaching the end 
of the procedure body. 


Form (e) is an if ‘statement. The conditional expression fol- 


lowing “if" and each “elseif" is evaluated until one of them is 
found to be true, in which case the statements following the 
corresponding "then" are executed. If none of the expressions 


evaluates to true then the statements following "else" are execu- 
ted; if no “else" is present then execution continues following 
the if statement. The conditional expressions must be of type 
Boolean. ; 


Form (f£) is the looping construct. The statements within the 
loop are repeated until one of its "exit" statements or a "re- 
turn" statement is executed. 


Form (g) is a loop exit. When executed, it causes an immedi- 
ate exit from the nearest enclosing loop. The optional "when" 
expression makes the exit conditional. If the expression, which 
must be Boolean, evaluates to true then the exit is executed, 
otherwise execution of the loop continues. An exit statement 
Cannot appear outside a loop. 


Form (h) is a case statement. The case expression is evalua- 
ted and used to select one of the alternative labels. The sta- 
tements which follow the matching label value are executed. If 
the case expression value does not match any of the label values 
then the statements following "otherwise" are executed. If no 
"otherwise" is present, the case expression must match one of the 
label values. When execution of the statements following the 
selected label is Sones ekeoe execution continues following the 
case statement. 


The root type of the case expression must be integer or Char. 
All of the label expressions must have the same root type as the 
case expression. Label expressions must be manifest, i.e., their 
values must be known at compile time. The values of all label 
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expressions in a given case statement must be distinct. The 
value of the manifest expression following the end of an alterna- 
tive must be equal to the first label expression of the alterna- 
tive. 


An implementation may limit the range of case label expression 
values to insure efficient code; this range will include at least 
the ranges of Char and ShortInt. 


Form (i) is a begin block. Begin blocks can be used to group 
local declarations within a procedure or function. In particu- 
lar, they can be used to make local binds. 


Forms (j) and (k) are the built-in collection operations New 
and Free (see “Collections"). 


VARIABLES AND CONSTANTS 
A variable is: 
[moduleId "."] id {componentSelector} 


The syntax for variables includes variable and constant re- 
ferences. An exported variable or constant is referenced outside 
the module in which it is declared using the "." operator. 


A componentSelector is one of: 


ae ( " expn *) t 
be, "id 


Form (a) allows subscripting of variable and constant arrays. 
The type of the subscript expression must be assignable to the 
index type of the array. The value of the subscript expression 
must be in the declared range of the index type of the array. 
Subscripts which appear in checked scopes are checked for validi- 
ty at run-time. 


Form (a) also allows references to elements of a collection. 
In this case, the subscript expression must be a pointer to an 
element of the collection. 


Form (b) allows record field selection. Fields of a record 
variable are referenced using the "." operator. 


Form (b) also allows standard component references (see "Stan- 
dard Components"). 
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EXPRESSIONS 
An expn is one of the following: 


variable 

literalConstant 

setTypeId "(" elementList ")" 
collectionId "." nil 

{moduleId "."] functionId ["(" expn {"," expn} ") "] 
[moduleId "."] converterId "(" expn ")" 
" cn expn ie rT) 

eo expn 

expn arithmeticOperator expn 

expn comparisonOperator expn 

not expn 

expn booleanOperator expn 

expn setOperator expn 
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The arithmeticOperators are +, -, * (multiply), div (trunca- 
ting integer divide) and mod (integer remainder). The mod opera- 
tor is defined by "x mod y = x - y*(x div y)". Operands of the 
arithmetic operators and unary minus must be integers or expres- 
Sions having root type integer. The arithmetic operators yield 


an integer result. (Note: +, - and * are also set operators; see 
below.) 
The comparisonOperators are <, >, =, <=, >= and "not =", 


Operands of comparison operators must either have equivalent 
types or the same root type; see "Type Equivalence and Assigna- 
bility". The comparison operators yield a Boolean result. 
Arrays and records cannot be compared. Sets and Boolean expres- 
sions can be compared for equality only. (Note: <= and >= are 
also set operators; see below.) 


The booleanOperators are "and" (intersection), "or" (union) 
and -> (implication). The Boolean operators and the "not" opera- 
tor take Boolean operands and yield a Boolean result. The 
Boolean operators are conditional; that is, if the result of the 
operation can be determined from the value of the first operand 
then the second operand is not evaluated. 


The set operators are + (set union), - (set difference), * 
(set intersection), <= and >= (set inclusion), and “in" and “not 
in" (element containment). The set operators +, - and * take 
operands of equivalent set types and yield a set result. The set 
Operators <= and >= take operands of equivalent set types and 
yield a Boolean result. The operators "in" and "not in" take a 
set as right operand and an integer expression as left operand. 
They yield a Boolean result. 


The order of precedence is among the following classes of 
Operators (most binding first): 


1. unary - 
2. *, div, mod 
ae +, > : 
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4. <, >, =, <*, >=, not =, in, not in 
5. not 

6. and 

Ve OF 

8. -—-> 


Expression form (a) includes references to constants and vari- 
ables including elements of arrays and collections, fields of 
records, and constants and variables exported from a module. 


Form (b) includes integer, character and string literal con- 
Stants. 


Form (c) is a set constructor. The setTypeId must be the name 
of a set type. The set constructor returns a set containing the 
specified elements. 


An elementList is one o€: 


a. [expn {"," expn}] 
b. all 


The element list is a (possibly empty) list of expressions of 
the base type of the set, or "all". If "all" is specified, the 
constructor returns the complete set. If no elements are speci- 
fied, the constructor returns the empty set. 


Expression form (da) is the null pointer value of the specified 
collection. 


Form (e) is a function call. Functions exported from a module 
are referenced outside the module using the “." operator. An 
actual parameter to a function must be an expression assignable 
to the parameter type. 


Form (£) is a type conversion. The type of the actual 
parameter is changed to the result type of the type converter. 
The actual parameter must be a variable or nonmanifest named con- 
Stant whose type is equivalent to the source type of the conver- 
ter. Type converters exported from a module are referenced out- 
side the module using the "." operator. 


BUILT-IN FUNCTIONS 


SE has three built-in functions, Chr, Ord and Long. "Chr(i)" 
returns the character whose machine representation is the _ posi- 
tive integer value i. "“Ord(c)" returns the positive integer 
machine representation of the character c. Chr and Ord are de- 
fined such that for all characters "c" in the machine character 
set, Chr(Ord(c)) = c. “Long(i)" forces the integer expression i 
to be extended to LongInt precision; see "Precision of Arithmet- 
ic". (Note: In full Euclid, the Ord built-in function is called 
"Char.Ord".) 
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STANDARD COMPONENTS 


SE defines two standard components, size and address. 
"T.size" returns the length in StorageUnits (typically bytes) of 
the machine representation of the variable or type T. 
"V.address" returns the AddressType machine address of the varia- 
ble V. The size and address standard components are not allowed 
for elements of packed arrays and fields of packed records. The 
address standard component is not allowed for variables declared 
"register". (Note: In full Euclid, the address standard com- 
ponent is allowed only for variables of type StorageUnit.) 


MANIFEST EXPRESSIONS 


A manifest expression is an expression whose value can be com- 
puted as a literal constant at compile time. The extent of such 
compile-time computation is implementation dependent, but every 
implementation will consider at least the following to be mani- 
fest: 


1. Integer and Char literal constants 

2. The Boolean values "true" and "false" 

3. Manifest named constants 

4. The arithmetic operations unary -, +, -, *, div 
and mod when both operands are manifest and both 
the operands and result lie in the range of 
SignedInt (at least -32768..32767) 

5. The built-in functions Chr and Ord when 
the actual parameter is manifest 


A manifestExpn is an expression whose value is manifest. A 
manifestConstant is a (possibly negated) literal constant or man- 


ifest named conStant. 


PRECISION OF ARITHMETIC 


The precision of an arithmetic operation or comparison is 
determined by the precision of the operands. Operands have one 
of three precisions which correspond to the standard types Sig- 
nedInt, UnsignedInt and LongInt. 


The precision of a variable or non-manifest named constant 
operand is determined by its declared type. If its type is Sig- 
nediInt, ShortInt or any subrange whose bounds both lie in the 
range of SignedInt then its operand precision is SignedInt. If 
its type is UnsignedInt or any subrange whose bounds. both lie in 
the range of UnsignedInt but not in SignedInt then its precision 
is UnsignedInt. Otherwise, its precision is LongInt. 


The precision of a literal or manifest named constant operand 
is SignediInt if its value lies in the range of SignedInt, Unsig- 
nedInt if its value lies in the range of UnsignedInt but not of 
SignedInt, and LongInt otherwise. 
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The precision of an arithmetic operation or comparison is 
LongInt if at least one operand has LongInt precision, Unsig- 
nedInt if at least one operand has UnsignedInt precision and 
neither has LongInt precision, and SignedInt otherwise. 


The precision of the result of an arithmetic operation is the 
precision of the operation. Every implementation will guarantee 
to obtain the arithmetically correct result if the result of an 
operation lies within the range of the result precision. If the 
arithmetically correct result lies outside the range of the 


result precision then the result may be meaningless. 
Note that the precision of an operation or comparison can 
always be forced to LongInt by extending the precision of one or 


both of the operands using the Long built-in function (see 
"Built-in Functions"). 


SOURCE INCLUSION FACILITY 


Other source files may be included as part of a program uSing 
the “include” statement. 


An includeStatement is: 
include stringLiteral 
The stringLiteral gives the name of a source file to be inclu- 
ded in the compilation. The include statement is replaced in the 
program source by the contents of the specified file. 
Include statements can appear anywhere in a program and can 


contain any valid source fragment. Included source files can 
themselves contain include statements. 
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II. CONCURRENCY FEATURES 


The Concurrent Euclid (CE) language is an extension of SE 
designed to allow concurrent programming with monitors. SE is a 
subset of Euclid but CE is not, because concurrency and monitors 
are not features of Euclid. | | 


The concurrency features of CE will be presented in the fol- 
lowing order: 


(1) processes, reentrant procedures and modules; 
(2) monitors, entry procedures and functions; 
(3) conditions, signalling and waiting; 

(4) simulation and the busy statement. 


PROCESSES 


Each CE module (including the main module) can have any number 
of concurrent processes in it. 


A moduleDeclaration is: 


var id ":" 
module 
[imports "(" [var] id {"," [var] id} ")"] 
[exports i id ee id} ea 
{{not] checked] 
{declarationInModule} 
[initially 
procedureBody] 
{process id ["(" memoryRequirement ") "] 
procedureBody} 
end module 


Each process is like a parameterless procedure. Concurrent 
execution of the processes of the module begins following execu- 
tion of the initially procedure of the module. A process ter- 
minates by executing its last statement or by executing a return 
Statement in its body. The process identifier is for documenta- 
tion only since processes cannot be called. 


Processes can communicate with each other by changing and 
inspecting variables declared in the module or imported into it. 
Generally, however, processes communicate by means of monitors. 


Each process requires a certain amount of memory space for its 


variables. When the process calls a procedure or function, the 
requirement increases to provide space for the new local varia- 
bles, When the procedure or function returns, the requirement 


decreases to its former. amount. The programmer can provide his 
own estimate of the process's required space as a parenthesized 
manifest integer expression following the keyword "process". 
This estimate is in StorageUnits (normally bytes) and can be 
based on previous program executions. If this estimate is omit- 
ted, the implementation provides a default space allocation. 
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All procedures and functions declared in a CE program are 
reentrant, meaning that they can be executed simultaneously by 
more than one process, 


Modules, monitors, procedures and functions cannot be nested 
inside a process. 


MONITORS 


A monitor is essentially a special kind of module which im- 
plements inter-process communication with synchronization. 


A declarationInModule is one of the following: 


- constantDeclaration 

- variableDeclaration 
typeDeclaration 
variableBinding 
moduleDeclaration 
monitorDeclaration 
collectionDeclaration 
procedureDeclaration 
functionDeclaration 
converterDeclaration 
assert ["(" expn ")"] 
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Monitors may only be declared inside modules. Monitors cannot 
be nested inside procedures, functions or other monitors. 


A monitorDeclaration is: 


var id ";" 

monitor 
{imports "(" [var] id {"," [var] id} ") "J 
[exports se Ga id Peet id} oy") 
[{not] checked] 
{declarationInMonitor} 
{initially 

procedureBody] 
end monitor 


The imports list of a monitor specifies the global identifiers 
which are accessible inside the monitor, exactly like the imports 
list in a module. 


The exports list of a monitor specifies those identifiers 
defined inside the monitor which may be accessed outside the mon- 
itor using the "." operator. Unlike modules, monitors cannot 
export variables. 


Procedures and functions which are exported from a monitor are 
called monitor entries. Entry procedures and functions of a mon- 
itor cannot be invoked inside the monitor. Outside the monitor, 
entry procedures and functions can be invoked exactly like the 
procedures and functions of a module, using the "." operator. 
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Procedures and functions which are entries of a monitor cannot 
be separately compiled except as part of the entire monitor. 


It is guaranteed that only one process at a time will be exe- 
cuting inside a monitor. As a result, mutually exclusive access 
to a monitor's variables is implicitly provided, since a monitor 
Cannot export any variables. If a process calls an entry of a 
monitor while another process is executing in the monitor, the 
calling process will be blocked and not allowed in the monitor 
until no other process is executing in the monitor. 


A declarationInMonitor is one of the following: 


a. constantDeclaration 
b. variableDeclaration 
c. typeDeclaration 

d. variableBinding 

e. conditionDeclaration 
f. collectionDeclaration 
g. procedureDeclaration 
h. functionDeclaration 
i. converterDeclaration 
j. assert ["(" expn ")"] 


Modules and monitors cannot be declared inside a monitor. A 
monitor cannot contain a nested process. 


Monitors can be separately compiled; see "Separate Compila- 
tion". 
CONDITIONS 
A conditionDeclaration is one of: 


a. var id ":" ({priority] condition 
b. var id ":" array indexType of [priority] condition 


The only place a condition can be declared is as a field of a 
monitor. The only allowed use of conditions is in the "wait" and 
"signal" statements and in the “empty" built-in function. Condi- 
tions cannot be assigned, compared or passed aS parameters. 
Arrays of conditions are allowed. Conditions may be imported 
"var" (or not). An imported condition can be used ina wait or 
Signal statement only if it is imported "var". 


Two new statements are introduced: 


wait "(" conditionVar ["," priorityValue] ")" 
signal "(" conditionVar ")" 


Where a conditionVar is: 
conditionId ["(" expn ")"] 
The wait and signal statements each specify a conditionVar. 
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Each of these must be a conditionId or a subscripted condition 
array. These statements can appear only in monitors, but not in 
a monitor's initially procedure. 


When a process executes a wait statement for condition C it is 
blocked and is removed from the monitor. When a process executes 
a Signal statement for condition C, one of the processes (if 
there are any) waiting for condition C is unblocked and allowed 
immediately to continue executing the monitor. The signalling 
process is temporarily removed from the monitor and is not al- 
lowed to continue execution until no processes are in the moni- 
tor. If no processes were waiting for condition C, the only 
effect of the signal statement is that the signalling process may 
be removed from the monitor. The signalling process cannot in 
general know whether other processes have entered the monitor 
before the signaller continues in the monitor. 


If the condition variable is declared with the "priority" 
option, the wait statement must specify a priority value; oth- 
erwise the priority value is not allowed in wait. The 
priorityValue is a SignedInt expression that must evaluate to a 
nonnegative integer value. The processes waiting for a priority 
condition are ranked in order of their specified priority values, 
and the process with the smallest priority value is the first to 
be unblocked by a signal statement. 


In the case of processes waiting for non-priority conditions, 
or waiting with identical priorities for a priority condition, 
the scheduling is "fair", meaning that a particular waiting  pro- 
cess will eventually be unblocked given enough signals on the 
condition. 


A predefined function named "empty" accepts a condition as a 
parameter. It returns the Boolean value “true" if no processes 
are waiting for the condition, otherwise "false". Like wait and 
signal, “empty” can appear only inside a monitor, but not in the 
initially procedure of a monitor. 


The variables in a monitor represent its state. For example, 
if a monitor allocates a single resource, only one variable in- 
side the monitor is needed and it can be declared as Boolean. 
When this variable is true, it represents the state in which the 
resource is available, when false it represents the state of 
being allocated. When a-_ process enters the monitor and finds 
that it does not have the desired state, the process leaves’ the 
monitor and becomes blocked by executing a wait statement on a 
condition. The condition corresponds to the state that the pro- 


cess is waiting for. Suppose a process enters a monitor and 
changes its state to a state that may be waited for by other pro- 
cesses. The process should execute a signal statement for the 


condition corresponding.to the new state. If there are processes 
waiting for this state transition, then they will be blocked on 
the condition, and one of them will immediately resume execution 
in the monitor. Because of this immediate resumption, the sig- 
nalled process knows the monitor is in the desired state, without 
testing monitor variables. The signalling process is allowed to 
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continue executing only when no other processes are in the moni- 
tor. If no processes were waiting on the condition, the only 
effect of the signal statement is to temporarily. remove the sig- 
naller from the monitor. 


As specified by Hoare, monitors and conditions are intended to 
be used in the following manner. The programmer should associate 
with the monitor's variables a consistency criterion. The con- 
sistency criterion is a Boolean expression that should be true 
between monitor activations, or whenever a process enters or 
leaveS a monitor. Hence, the programmer should see that it is 
made true before each signal or wait statement in the monitor and 
before each return from an entry of the monitor. The programmer 
Should also associate a Boolean expression, call it Ei, with each 
condition Ci. The expression Ei should be true whenever a signal 
is executed for condition Ci. A process that is unblocked after 
waiting for a condition knows that Ei is true because the signal- 
led process (not the signalling process) executes first. (The 
consistency criterion and each Ei for a condition do not neces- 
sarily appear as executable code in the monitor.) In general, 
when a process changes the monitor's state so that one of the 
awaited relations Ei becomes true, the corresponding condition Ci 
should be signalled. 


THE BUSY STATEMENT 


A statement is introduced to allow simulation using timing 
delays: 


busy a Ga time LD 


The time must be a nonnegative SignedInt expression. The busy 
statement can be understood in terms of simulated time recorded 
by a system clock. This clock is set to zero at the beginning of 
execution of a program. With the exception of the busy statement 
(or wait statements causing an indirect delay for a busy sta- 
tement), statements take negligible simulated time to execute. 
When the programmer wants to specify that a certain action takes 
time to complete, the busy statement is used. The process that 
executes the busy statement is delayed until the system clock 
ticks (counts off) the specified number of time units. 
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IIIT. SEPARATE COMPILATION 


This section describes the extensions made to CE to allow 
separate compilation of procedures, functions, modules and moni- 
tors. 


EXTERNAL DECLARATIONS 


Procedures, functions, modules and monitors may be declared 
"external", which means that they are to be separately compiled 
and joined with the program at link time. Due to linker restric- 
tions, a particular implementation may be forced to place a limit 
on the number of significant characters in external module, moni- 
tor, procedure and function identifiers. 


An externalProcedureDeclaration is: 
procedure id ["(" [var] id ":“ parameterType 


{"," [var] id ":" parameterType} ")"] 
external 


An externalFunctionDeclaration is: 


function id ["(" id ":" parameterType 
{"," id ":" parameterType} ") "] 
returns id ":" resultType "=" 
external 


An externalModuleDeclaration is: 


var id ";:" 
external module 
{imports “(" [{var] id {"," [var] id} ")"] 
{exports nyu id {8 id} my my 
{declarationInExternalModule} 
end module 


A declarationInExternalModule is one of: 


manifestConstantDeclaration 
typeDeclaration 
collectionDeclaration 
converterDeclaration 
externalProcedureDeclaration 
externalFunctionDeclaration 
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An externalMonitorDeclaration is: 


var id “":" 
external monitor 
[amnports, "" Evar). td: 4."5" (varl id} *)*) 
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[exports i id {es id} my "y 
{declarationInExternalMonitor} 
end monitor . 


A declarationInExternalMonitor is one of: 


a. manifestConstantDeclaration 
b. typeDeclaration 

c. collectionDeclaration 

dad. converterDeclaration 

e. externalProcedureDeclaration 
f. externalFunctionDeclaration 


An external declaration can appear in place of the real de- 
claration and specifies that the corresponding procedure, func- 
tion, module or monitor is to be compiled separately. 


Processes and initially procedures of modules cannot be de- 
clared external. Procedures and functions which are entries of a 
monitor cannot be declared external except as part of an external 


monitor declaration. ‘Nonmanifest and array named constants can- 
not be declared in an external module or monitor. 


COMPILATIONS 


A compilation can consist of a main program (see "Programs") 
or a separate compilation. 


A separateCompilation is: 
{separateDeclaration} 


Each separateDeclaration is one of the following: 


manifestConstantDeclaration 
typeDeclaration 
collectionDeclaration 
converterDeclaration 
procedureDeclaration 
functionDeclaration 
moduleDeclaration 
monitorDeclaration 
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Each separateDeclaration can be a manifest constant declara- 
tion, a type declaration, a collection declaration, : a procedure 
or function declared as “external” in another compilation, or a 
module or monitor declared as "external" in another compilation. 


Separately compiled procedures, functions, modules and moni- 
tors can be linked to form a complete program. Variables cannot 
be separately compiled and are not linked across compilations. 
Consistency of constants, types and collections is not automati- 
cally checked across compilations. Consistency of the type and 
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number of formal parameters and function results between the 
external declaration and the separate compilation of separately 
compiled procedures and functions is not automatically checked. 


Separately compiled modules and monitors will be initialized 
at the point of the corresponding “external” declaration. Note 
that since execution of a program consists of initializing the 
main module (see "Programs"), only those modules and monitors 
which are declared in the main module or a module nested within 
it will be initialized. 


LINKING OF COMPILATIONS 


A complete program will typically consist of a main module 
compilation linked together with the separate compilations of any 
procedures, functions, modules and monitors declared as "“exter- 
nal“ in it. The compilations must be linked such that the entry 
point of the program is the beginning of the main module compila- 
tion. (Under many systems, this means simply that the main modu- 
le compilation must be the first in the list of object modules to 
be linked together.) 
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APPENDIX 1. 
COLLECTED SYNTAX OF CONCURRENT EUCLID 


The syntax of SE is given first. Throughout the following, 
{item} means zero or more of the item, and [item] means the item 
is optional. 


The following abbreviations are used: 


id for identifier 
expn for expression 
typeDefn for typeDefinition 


Semicolons are not required, but they may optionally appear 
following statements, declarations and import, export and checked 
clauses. 


A program is: 


noduleDeclaration 


A moduleDeclaration is: 


Var ‘id:-" 3" 

module 
[imports “(" [var] id {"," [var] id} ")"] 
[exports ah id ea id} 2s ea 
[{not] checked] 
{declarationInModule} 
{initially 

procedureBody] 
end module 


A declarationInModule is one of the following: 


constantDeclaration 
variableDeclaration 
typeDeclaration 
variableBinding 
moduleDeclaration 
collectionDeclaration 
procedureDeclaration 
functionDeclaration 

»- converterDeclaration 
- assert ["(" expn ")"] 


ue TQmonadow 


A constantDeclaration is one of: 


a. [pervasive] const id ":=" manifestExpn 
b. [pervasive] const id ":" typeDefn “:=" expn 
c. [pervasive] const id ":" typeDefn ":=" 

"(" manifestExpn {"," manifestExpn} ")" 
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d. [pervasive] const id ":=" stringLiteral 


A manifestExpn is: 


expn 


A variableDeclaration is: 


[register] var id [("(" at manifestExpn ")"] ":" typeDefn 
[ "=" expn] 


A typeDeclaration is: 
[pervasive] type id "=" typeBody 


The typeBody is one of: 


a. typeDefn 
b. forward 


A typeDefn is one of the following: 


standardType 

manifestConstant ".." manifestExpn 
[packed] array indexType of typeDefn 
set of baseType 

[packed] recordType 

pointerType 

namedType 
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A standardType is one of: 


SignedInt 
UnsignedInt 
LongiInt 
ShortInt 
Boolean 
Char 
StorageUnit 
AddressType 
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A manifestConstant is one of: 


P ["-"] literalConstant 
‘ ("—-"] [moduleId] "." manifestConstantId 
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A manifestConstantId is: 


id 


An indexType is one of: 


a. Char 
b. manifestConstant ".." 
Cc. namedType 


A baseType is one of: 


a. O".." manifestExpn 
b. namedType 


A recordType is: 


record 
var id ":" typeDefn 


{var id ":": typeDefn} 
end record 


A pointerType is: 


"*" collectionIld 


A collectionId is: 


id 


A namedType is: 
[moduleId "."] typelId 


A modulelId is: 


id 


A typeld is: 
id 


A variableBinding is one of: 


bind [register] [var] 


manifestExpn 


id to variable 


ae 
b. bind "(" [register] [var] id to variable 


{"," [register] 


[var] id to variable} 


a 
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A collectionDeclaration is: 


var id ":" collection of typeDefn 


A procedureDeclaration is: 


procedure id ["(" [var] id ":" parameterType 
"," ({var] id ":" parameterType} ")"] "=" 
procedureBody : 


A functionDeclaration is: 


function id ["“(" id “":" parameterType 
{"," id ":" parameterType} ") "] 
returns id ":" resultType "=" 
procedureBody 


A parameterType is one of: 


a. typeDefn 

b. [packed] array manifestConstant ".." parameter 
typeDe fn 

c. universal 


A resultType is one of: 


a. standardtType 

b. manifestConstant ".." manifestExpn 
c. set of baseType 

d. pointerType 

e. namedType 


A procedureBody is: 


[imports "(" [var] id {"," [var] id} ")"] 
begin 

{[{not] checked] 

{declarationInRoutine} 

{statement} 
end [id] 


A declarationInRoutine is one of: 


a. constantDeclaration 
b. variableDeclaration 
c. typeDeclaration 

dad. variableBinding 

e. collectionDeclaration 
f. converterDeclaration 
g.- assert ["("expn") "] 
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of 


A converterDeclaration is: 


converter id "(" typeId ")" returns typeld 


A statement is one of: 


a. variable “":=" expn 
b. [moduleId"."] procedureId ["(" expn {"," expn} ") "] 
c. assert ["("expn") "] 
d. return ["("expn") "] 
e. if expn then 
{statement} 
{elseif expn then 
{statement} } 
{else 
{statement} ] 
end if 
£. loop 
{statement} 
end loop 
g. exit [when expn] 
h. case expn of 
manifestExpn {"," manifestExpn} "=>" 
{statement} 
end manifestExpn 
{manifestExpn {"," manifestExpn} “=>" 
{statement} 
end manifestExpn} 
[otherwise "=>" 
{statement} ] 
end case 
i. begin 
{declarationInRoutine} 
{statement} 
end 
j}. collectionId "." New "(" variable ")" 
k. collectionId "." Free "(" variable ")" 


A procedureld is: 
id 
A variable is: 


[moduleId "."] id {componentSelector} 


A componentSelector is one of: 


a - " ce expn uw ) " 
bs ~~" 2d 

ec. “<" sige 

qd. "." address 
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An expn is one of the following: 


Be wu ro ho aa ow 
e668 


variable 

literalConstant 

setTypeId "(" elementList ")" 
collectionId "." nil | 


[moduleId "."] functionId ["(" 
[moduleId "."] converterId "(" 
w ( i] expn ") ae 

wot expn 


expn arithmeticOperator expn 
expn comparisonOperator expn 
not expn 

expn booleanOperator expn 
expn setOperator expn 


A setTypeld is: 


id 


A elementList is one of: 


Ae 
b. 


fexpn {"," expn}] 
all 


A functionId is one of: 


a. 
b. 
Cc. 
d. 


id 
Chr 
Ord 


Long 


A converterld is: 


id 


An arithmeticOperator is one of: 


a. 
b. 
C. 
d. 
e. 


& 
div 
mod 


A comparisonOperator is.one of: 


a BA 


expn { rT] hy 
expn ny " 


expn} 


") "j 


Ey 


>= 
not 


A booleanOperator is one of: 


A setOperator 


and 
or 
-> 


is one of: 


a. + 

b. - 

Cc. * 

dad. <= 

e. >= 

f.. “in 

g- not in 
Note: The order of precedence is among the following classes of 
operators (most binding first): 

l. unary - 

2. *, div, mod 

3. +, > 

4. <, >, =, <=, >=, not =, in, not in 

5. not 

6. and 

Te: ~OL 

8. —-> 


An includeStatement is: 


include stringLiteral 


Note: Include statements can appear anywhere in a program. 


a 


The following changes and additions are made to form CE: 


A moduleDeclaration is: 


var id “;" 
module 
[imports "(" [var] id {"," [var] id} ")"] 
[exports a id fos id} sd | 
{{not] checked] 
{declarationInModule} 
[initially 
procedureBody] 
{process id ["(" memoryRequirement ") "] 
procedureBody} 
end module 


A memoryRequirement is: 


manifestExpn 


A declarationInModule is one of the following: 


constantDeclaration 
variableDeclaration 
typeDeclaration 
variableBinding 
moduleDeclaration 
monitorDeclaration 
collectionDeclaration 
procedureDeclaration 
functionDeclaration 
converterDeclaration 
assert ["(" expn ") "J 


Ae TO moaanom 


A monitorDeclaration is: 


var id “:" 


monitor 
[imports "(" [var] id {"," [var] id} ")"] 
[exports Ce id ee id} ie ae | 


{{not] checked] 
{declarationInMonitor} 
[initially 
procedureBody] 
end monitor 


A declarationInMonitor is one of the following: 
a. constantDeclaration 
b. variableDeclaration 
Cc. typeDeclaration 


i SE Ga 


»- variableBinding 

- conditionDeclaration 
- collectionDeclaration 
- procedureDeclaration 
- f£unctionDeclaration 
converterDeclaration 
assert ["(" expn ")"] 


A conditionDeclaration is one of: 
var id ":" [priority] condition 


a. 
b. var id ":" array indexType of [priority] condition 


A statement is one o€: 


a. variable ";=" expn 

b. [moduleId"."] procedureId [{"(" expn {"," expn}") "] 
ec. assert ["("expn") "] 

qd. return ["("expn") "] 

e. if expn then 


{statement} 
{elseif expn then 
{statement} } 
{else 
{statement} ] 
end if 
£. loop 
{statement} 
end loop 
g. exit [when expn] 
h. case expn of 
manifestExpn {"," manifestExpn} "=>" 
{statement} 
end manifestExpn 
{manifestExpn {"," manifestExpn} "=>" 
{statement} 
end manifestExpn} 
[otherwise “=>" 
{statement} ] 
end case 
i. begin 
{declarationInRoutine} 
{statement} 
end 
j}- collectionId "." New "(" variable ")" 
k. collectionId "." Free "(" variable ")" 
1. wait "(" conditionVar ["," priorityValue] ")" 
m. signal “"(" conditionVar ")" 
hs “busy "(time ™)" 


A modulelId is: 


moduleOrMonitorIid 


moduleOrMonitorld is: 


id 


conditionVar is: 


conditionId [{"(" 


conditionId is: 


id 


priorityValue is; 


expn 


time is: 


expn 


functionId is one of: 


a. id 

b. Chr 
ec. Ord 
d. Long 
e. empty 


expn ") "] 
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The following extensions allow Separate compilation of 
cedures, functions, modules and monitors: 


An externalProcedureDeclaration is: 


‘procedure id [{"(" [var] id “":" parameterType 


{"," {var] id ":" parameterType} ")"] "=" 
external 


An externalFunctionDeclaration is: 


e 


function id ["(" id ":" parameterType 


{"," id ":" parameterType} ") "] 
returns id ":" resultType "=" 
external 


An externalModuleDeclaration is: 


var id “;:" 


external module 
{imports "(" [var] id {"," [var] id} ") "] 
[exports wie id ti," id} ") w 
{declarationInExternalModule} 

end module 


A declarationInExternalModule is one of: 


momaaos 


manifestConstantDeclaration 
typeDeclaration 
collectionDeclaration 
converterDeclaration 
externalProcedureDeclaration 
externalFunctionDeclaration 


An externalMonitorDeclaration is: 


Var id *=" 


external monitor 


[imports "(" [var] id {"," [var] id} ")"] 
[exports "(" id {"," id} ")"] 
{declarationInExternalMonitor} 


end monitor 


A declarationInExternalMonitor is one of: 


o0aan»on 


manifestConstantDeclaration 
typeDeclaration 
collectionDeclaration 
converterDeclaration 
externalProcedureDeclaration 


ee ae 


pro- 


f. externalFunctionDeclaration 


Note: An external declaration can appear in place of the real 
declaration anywhere in a program. 


A manifestConstantDeclaration is: 


[pervasive] const id ":=" manifestExpn 


A separateCompilation is: 


{separateDeclaration} 


Each separateDeclaration is one of the following: 


manifestConstantDeclaration 
typeDeclaration 
collectionDeclaration 
converterDeclaration 
procedureDeclaration 
functionDeclaration 
moduleDeclaration 
monitorDeclaration 


Two moana o mw 


° 


The following are reserved words of Euclid. 
identifiers in SE and CE programs. 


used as 


APPEN 


DIX 2. 


in the SE subset are marked with an *. 


*abstraction 
*any 

begin 

case 
collection 
*decreasing 
else 
exports 
*from 

in 
*invariant 
not 

packed 

*pre 

return 

* thus 

var 


*aligned 
array 
bind 
*checkable 
const 
*default 
elseif 
*finally 
function 
include 
loop 

of 
parameter 
procedure 
returns 
to 

when 


all 

assert 
*bits 
checked 
converter 
*dependent 
end 

*for 


ALE 


initially 
machine 
or 
pervasive 
* readonly 
set 


type 
*with 


The following are additional reserved 
These also must not be used as identifiers in SE and CE programs. 


busy condition 
priority process 
universal wait 

The following 


empty 
register 


are predefined identifiers of Euclid. 


KEYWORDS AND PREDEFINED IDENTIFIERS 


These must not be 
Those which are not 


and 

at 

* bound 
*code 
*counted 
div 

exit 
forward 
imports 
*inline 
mod 
otherwise 
*post 
record 
then 

* unknown 
*xor 


of SE and CE. 


monitor 
signal 


In gen- 


eral, these are pervasive and must not be redeclared in SE and CE 


programs. Those 

an *, 

*ADS address 
*BaseType Boolean 
*ComponentType false 
*Index *IndexType 
*ItsType *last 

New nil 

Ord *Pred 

size *sizeInBits 
*StringIndex *stringMaxLength 
*SystemZone true 


AddressType 


Char 
*first 
*Integer 
*Max 


*ObjectType 


*refCount 


StorageUnit 


UnsignediInt 


which are not in the SE subset are marked with 


*alignment 
Chr 

Free 
*itsTag 
*Min 

*Odd 
SignedInt 
*String 
*Succ 


The following are additional predefined identifiers of SE and 
CE. These also must not be redeclared in SE and CE programs. 


Long 


LongiInt 
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ShortInt 
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APPENDIX 3. 
INPUT/OUTPUT IN CONCURRENT EUCLID 


This paper presents the standard input/output package for SE 
and CE. The user can access the I/O facility by including in his 
program the stub input/output module which corresponds to the 
level of I/O which his program requires. In this way, the user's 
compiled and linked program will include code only for the I/0 
facilities required. 


The package provides four levels of sophistication, which are 
called "IO/1" through "I0/4". Each level includes all the facil- 
ities of the previous levels plus certain new features. The 
levels are as follows: 


10/1: Terminal (standard) input and output; Formatted text 
input/output of integers, characters and strings (Get and 
Put): 


l0/2: Program argument sequential files; Open and close on ar- 
gument files; Formatted text input/output of integers, 
characters and strings to files (FGet and FPut); Internal 
representation input/output of integers, characters’ and 
strings to files (Read and Write); End of file detection 
(EndFile). 


I0/3: Temporary and non-argument sequential files (Assign, Deas- 
Sign, Delete); Program arguments (FetchArg); Program error 
exit (SysExit). 


10/4: Record, array and storage input/output (Read and Write); 
Random access files (Tell and Seek); Error detection 
(Error). 


The procedures and functions of the input/output system are 
all part of the module "IO" and must be referenced using "I0O.". 
The types and constants which form the interface to the module 
are global. The user can access the level n facilities of the 
input/output module by including the statement 


include '/usr/lib/coneuc/IOn' 
as the first declaration in his main module. 


We now describe the input/output facilities in detail. 


10/1: Terminal Formatted Text I/0 


pervasive const newLine := $SN 
pervasive const endOfFile := SSE 
pervasive const maxStringLength := 
{ Implementation defined; >= 128 } 
Strings read and written by the input/output routines may be 
up to maxStringLength characters in length. 
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IO.PutChar (c: Char) 
Prints the character c on the terminal. 


IO.PutInt (i: SignedInt, w: SignedInt) 

Prints the integer i on the terminal, right justified ina 
field of w characters. Leading blanks are supplied to fill 
the field. If w is an insufficient width, the value is 
printed in the minimum possible width with no leading 
blanks. In particular, if wis 1 then the exact number of 
characters needed is used. The specified width must be 
greater than zero and less than maxStringLength. 


I0.PutLong (i: LongInt, w: SignedInt) 
Same as I0.PutInt for long integers. 


T0.PutString (s: packed array l..parameter of Char) 
Prints the string s onthe terminal. The string must be 
terminated by an endOfFile character ('SE'), which is not 
output. It can contain embedded newLines ('SN') if desired. 
(Note: An endOfFile character ($$E) can be output using 
PutChar.) 


I0.GetChar (var c:Char) 
Gets a the next input character from the terminal. End of 
file is indicated by a return of endOfFile (SSE). 


I0.GetInt (var i: SignedInt) 
Gets an integer from the terminal. The input must consist 
of any number of optional blanks, tabs and newlines, fol- 
lowed by an optional minus sign, followed by any number of 
decimal digits. 


I0.GetLong (var i: LongInt) 
Same as 1I10.GetInt for long integers. 


IO0.GetString (var s: packed array 1..parameter of Char) 

Gets a line of character input from the terminal. The re- 
turned string may be up to maxStringLength characters in 
length. The string returned is ended with the newLine 
character ('SN') followed by an endOfFile character ('SE') 
if it is a complete line, and by the endOfFile character 
only if it is a partial line (i.e., if the input line ex- 
ceeds maxStringLength characters in length). End of file is 
indicated by returning a string containing endOfFile ('SE') 
as the first character. 


10/2: Sequential Argument File I/o 


pervasive const stdInput := 
pervasive const stdOutput := -l 
pervasive const stdError := 
pervasive const maxArgs := 
pervasive const maxFiles := 

{ Implementation defined; >= maxArgs+5 } 
type File = stdInput..maxFiles 


{ Implementation defined; >= 9 } 


se AX es 


Concurrent Euclid input/output refers to files using a_ file 
number. Certain file numbers are preassigned as follows: -2 
refers to the terminal input; -l is the terminal output; 0 
is the standard diagnostic output. The file numbers 
l..maxArgs refer to the program arguments. The remaining 
File numbers (maxArgstl..maxFiles) can be dynamically assig- 
ned to files using the "IO.Assign" operation; see “IO/3". 


pervasive const inFile := 0 
pervasive const outFile := 1 
pervasive const inOutFile := 2 
type FileMode = inFile..inOutFile 


Files can be opened for input, output, or input/output using 
modes inFile, outFile and inOutFile respectively. (Note: 
The input/output mode is not available under Unix V6.) 


IO0.Open (f: File, m: FileMode) 
IO0.Close (f: File) 


With the exception of terminal input/output and the standard 
diagnostic output, files must be opened before they are used 
and closed before the program returns. Open opens an exis- 
ting file for the operations specified by the mode. I£ the 
opened file does. not exist, it is created. The file number 
specified must be a preassigned file number or a file number 
returned from a call to "I0O.Assign"; see "IO0/3". 


IO. FPutChar (f: File, c: Char) 

I0.FPutInt (f: File, i: SignedInt, w: SignedInt) 

I0.FPutLong (f: File, i: LongInt, w: SignedInt) 

[O.FPutString (f: File, s: packed array 1..parameter of ener} 
IO0.FGetChar (f: File, var c: Char) 

IO.FGetInt (f£: File, var i: SignedInt) 

I0.FGetLong (f: File, var i: LongInt) 

IO.FGetString (f: File, var s: packed array 1l..parameter of Char) 


These operations are identical to the terminal input/output 
operations of IO/l except that the pat or get is done on the 
specified file. 


IO.WriteChar (f: File, c: Char) 


Writes the internal representation of character c to the 
specified file. 


IO0.WriteInt (f: File, i: SignedInt) 


Writes the internal representation of integer i to the 
specified file. 


IO0.WriteLong (f: File, i: LongInt) 


Writes the internal representation of long integer i to the 
specified file. 


IO.WriteString (f:File,.s: packed array 1..parameter of Char) 


Writes the internal representations of the characters in the 
String s to the specified file. 


IO0.ReadChar (f: File, var c: Char) 


Reads a character in internal representation from the 
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specified file into c. 


IO0.ReadInt (f: File, var i: SignedInt) 
Reads an integer in internal representation from the speci- 
fied file into i. 


IO0.ReadLong (f: File, var i: LongInt) 
Reads a long integer in internal representation from the 
specified file into i. 


IO0.ReadString (f: File, var s: packed array 1l..parameter of Char) 
Reads a string of characters terminated by a newLine charac- 
ter ('SN') in internal representation from the specified 
file into s. The returned string may be up to max- 
StringLength characters in length. The string returned is 
ended with the newLine character ('SN') followed by an 
endOfFile character ('SE') if it is a complete line, and by 
the endOfFile character only if it is a partial line (i. Qe, 
if the input line exceeds maxStringLength characters in 
length). End of file is indicated by returning a string 
containing endOfFile ('SE') as the first character. 


IO. EndFile (f: File) 
A function which returns true if the last operation on the 
specified input file encountered end of file and false oth- 
erwise,. 


I0/3: Temporary and Non-argument Files 


pervasive const maxArgLength := 
{ Implementation defined; >= 32 } 
File names and arguments to a program may be up to maxAr- 
gLength characters in length. 


I0.Assign (var f£: File, s: packed array 1..parameter of Char) 
A file number is assigned to the file name supplied in s. 
The file name is given as a string terminated by the endOf- 
File character ('SE'), which is not part of the name. Be- 
fore the file can be used it must be opened using "I0.Open". 


I0.Deassign (f: File) 
The specified file number is freed for assignment to another 
File name. An open file cannot be deassigned. 


I0.Delete (f: File) 
The specified file is destroyed. An open file cannot be 


deleted. Note that a program can have temporary files using 
"IO.Assign" and "I0.Delete". 


I0.FetchArg (n: 1..maxArgs, var s: packed array 1..parameter of 
Char) 
The program argument specified by "n" is returned in string 
Ss. The returned string is terminated by the endOfFile 
character ('SE') and may be up to maxArgLength characters in 
length. 
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IO0.SysExit (n: SignedInt) 
Terminate program execution with the specified return code. 
(ConEuc programs return 0 by default.) 


10/4: Structure Input/Output and Random Access Files 


IO.Write (f: File, u: universal, n: SignedInt) 
The number of StorageUnits specified by "n" are written to 
the file from u. Write can be used to write out whole ar- 
rays and records using a call of the form “IO.Write (f, v, 
v.Size)". The value of n must be positive or zero. 


TO0.Read (f: File, var u: universal, n: SignedInt) 
The number of StorageUnits specified by "n" are read from 
the file into u. Read can be used to read in whole arrays 
and records using a call of the form "I0O.Read (f, v, 
v.size)". The value of n must be positive or zero. 


type FileIndex = LongInt 

I0.Tell (£: File, var x: FileIndex) 

I0.Seek (f: File, x: FileIndex) 
These operations-provide random access input/output by al- 
lowing the program to sense a file position, represented as 
a long integer, and reset the file to a remembered position. 
Tell returns the current position of the specified file. 
Seek sets the current position of the specified file to the 
position specified by the value of x. The representation of 
file indices is implementation-dependent. (Note: "I0.Tell" 
‘and "I0.Seek" are not Supported under Unix V6.) 


IO.Error (f: File) 
A function which returns true if the last operation on the 
specified file encountered an error and false otherwise. 


Interfacing to Unix* 


The input/output package is based on standard Unix 
input/output and is designed to be interfaced to Unix with a 
minimum of overhead. The Unix implementation is written in C and 
uses only facilities of the C "stdio" package. This implementa- 
tion can be compiled unchanged under both V6 and V7 Unix. 


Unix* is a trademark of Bell Laboratories. 
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APPENDIX 4. 
PDP-11 IMPLEMENTATION NOTES 


This section gives details of the implementation of CE for the 
PDP-1ll under Unix* and provides information necessary for inter- 
facing with CE programs. 

DATA REPRESENTATION 


The following gives the storage representations of the various 
CE data types used by the PDP-11 implementation. 


Type Representation 
SignedInt and 
Subranges contained 16-bit signed word 


in -32768..32767 


UnsignedInt and 


subranges contained 16-bit unsigned word 
in 0..65535 but 
outside -32768..32767 


LongInt and 32-bit signed doubleword, word 
subranges outside aligned; high order word has 
the above the lower address 


ShortInt and 


packed subranges 8-bit unsigned byte 

in 0..255 

Boolean 8-bit unsigned byte; true = 1l, 
false = 0 

Char 8-bit unsigned byte 

StorageUnit 8-bit unsigned byte 

AddresstType, 

pointers and binds 16-bit unsigned word 

sets of 0..7 8-bit unsigned byte; element 0 


is low order bit, element 7 is 
high order bit 


sets of 0..15 16-bit unsigned word; element 0 


is low order bit, element 15 is 
high order bit 


REGISTER USAGE 
The following register assignments are used by the PDP-1l 


implementation. 
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Register Use 


RO, Rl function results, scratch 
R2, R3 scratch 
R4 line number, register variables 


and binds 


R5 register variables and binds 


Since the CE implementation uses the stack pointer register (SP) 
to address local variables in procedures and functions, there is 
no local base register. 


Function results whose data representation is a byte or _ word 
are returned in RO. Doubleword results are returned in RO and 
Rl, with the high order word in RO. 


In order to attain highly efficient code for non-scalar as- 
signments, subscripting and LongInt arithmetic, the CE compiler 
uses four scratch registers rather than the two used by the C 
compiler. In particular, CE uses R2 and R3 for scratch and hence 
does not save and restore them at procedure and function entry 
and exit. Since the PDP-1l1 C compiler uses R2 and R3 for re- 
gister variables, C routines which call CE procedures and func- 
tions can use at most one register variable. There is no such 
restriction on C routines called from CE programs. 


Register R5 (and R4 when line numbering is turned off, see 
below) are used for user variables and binds which are explicitly 
declared “register". 


When run-time line numbering is turned on (which is the de- 
fault), the CE compiler generates code to maintain the source 
file and line number in the line number register (R4) during exe- 
cution. This aids in debugging since the "cedb" program can 
obtain the source file name and line number from the core dump 
following a run-time program failure (e.g., assertion failure, 
subscript or case tag out of range, etc.). 


The contents of the line number register is interpreted asa 5 
digit unsigned decimal number, the first two digits of which give 
the source include file number and the last three of which give 
the source line number within file. Source file numbers are 
assigned sequentially starting with 1 for the main source file. 
Source files longer than 999 lines are assigned a new file number 
for each 1000 lines of source. 


Run time line numbering can be turned off using the "-1" com- 
piler toggle. 
CALLING CONVENTIONS 
CE procedures and functions which are (a) declared "external", 


mi BD os 


(b) Separately compiled, or (c) exported from a separately com- 
piled module or monitor, are called using the C calling conven- 
tion. A more efficient calling convention is used for calls 
between CE routines within a single compilation. 


Unlike C routines, CE procedures and functions do not save and 
restore all of the caller's registers, but rather save and res- 
tore only those registers which they actually use. Note that 
since registers RO-R3 are considered scratch registers by the CE 
compiler, CE routines never save and restore RO-R3. This means 
that C routines which call CE routines can use at most one re- 
gister variable. C routines which are called from CE may of 
course use as many register variables as they wish. Assembly 
routines called from CE can use RO-R3 as scratch and need not 
save and restore them. (Exception: the CE built-in routines are 
called using a special calling convention and must save and res- 
tore all registers which they use). 


EXTERNAL NAMES 


CE procedures and functions which are (a) declared "external", 
(b) separately compiled, or (c) exported from a separately com- 
piled module or monitor, are assigned external names so that they 
may be linked with and/or called from other compilations and pro- 
grams. On the PDP-1ll under Unix, these names consist of the 
routine name preceded by an underscore character. Because of 
Unix linker restrictions, only the first seven characters of 
external names are significant and hence care must be taken to 
avoid confilicts. The "initially" routine of an external module 
or monitor is given the name of the module/monitor. | 


PARAMETER PASSING 


Like C, CE passes parameters on the PDP-ll stack. Unlike C, 
however, CE pushes parameters onto the stack in the order in 
which they appear in the call (C reverses this order). Hence C 
procedures and functions which are called from CE (and CE pro- 
cedures and functions which are called from C) must declare their 
formal parameters in reversed order. 


Value parameters as defined in the CE language specification 
are passed as values on the stack. Byte values are passed in the 
low order byte of a 16-bit word. Reference parameters are passed 
as 16-bit word addresses. 


A parameter passed to array formal parameter declared using 
the "parameter" keyword as upper bound is passed with an extra 
unsigned word parameter following the array address. This extra 
parameter gives the number of elements in the array minus one. A 
parameter passed to a “universal" formal parameter is passed as 
an address only. 
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RUN-TIME CHECKING 


When run-time checking is turned on (which is the default), 
the CE compiler will generate code to check assert statements, 
subscript ranges and case selector ranges during execution. It 
will not generate code to check ranges in assignments and over- 
flow in expressions at run-time. The checking code uses an il- 
legal instruction of the form “jsr r0O,rN" to abort the program 
when a run-time check fails. The second register number in the 
instruction is an abort code indicating the reason for the abort. 
The following table gives the abort codes used by the PDP-1l 
implementation. 


Aborting instruction Reason for abort 

jsr r0O,r0 assertion failure 

jsr r0,rl subscript out of range 

jsr r0,r2 case selector out of range 

jsr r0,4r3 function failed to return a value 


The "“cedb" utility will automatically determine the source 
file name, source line number and reason for abort from the core 
File produced by a run-time abort. 


All run-time checking can be turned off using the "“-k" com- 
piler toggle. 


Unix* is a trademark of Bell Laboratories. 
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absolute address, 
variable at 6 


actual parameter 
address 


14 


standard component 19 
AddressType 7 
aliasing 10, 12, 15 
all, in set constructor 18 


allocate 10 
alternative label 
and operator 17 
arithmetic operation, 

precision of 19 
arithmetic operator 
array constant 6 
array type 8 
assert statement 
assignability 9 
Assign file utility 45 
assignment statement .14 
at clause 6 
base type 8 
begin block 
bind 9 


LS 


17 


L5 


16 


blocked process 24 
Boolean 7 . 
boolean operator 17 


built-in function 18 
busy statment 25 
calling conventions, 
of PDP-1ll 
implementation 48 
case alternative label 
case statement 15 
Char 7 
character literal 2 
character set 2 
checked, 
module or monitor 4 
procedure or 
function 


iS 


£3 


Chr built-in function 18 
Close file utility 44 
collection 8, 10 
collection declaration 10 
collection element 10, 16 
comment 3 

comparison operator 1/7. 


compilation 27 
concurrency 21 
concurrent process 
condition 23 


21 


INDEX 
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23 
25 


condition declaration 
consistency criterion 
constant declaration 5 
data representation, 

PDP-11l 

implementation 47 
Deassign file utility 
declaration, 

external 26 

in external module 

in external monitor 

in module 5, 22 

in monitor 23 

in procedure 

or function 

separate 27 
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